Return-Path: <corraltalkadmin@lassosmart.com>
Received: from 209.209.48.85 (209.209.48.85) by pointinspace.com with SMTP
 (Eudora Internet Mail Server 3.0.3); Sat, 26 May 2001 11:15:38 -0700
Received: from miazaki.bopjet.net (64.69.73.18) by pointinspace.com
 with
 SMTP (Eudora Internet Mail Server 3.0.3) for
 <corraltalk@lassosmart.com>;
 Sat, 26 May 2001 11:11:28 -0700
Received: (qmail 24289 invoked from network); 26 May 2001 18:09:05
 -0000
Received: from unknown (HELO jj) (212.67.97.203)
  by miazaki.bopjet.net with SMTP; 26 May 2001 18:09:05 -0000
Sender: corraltalk@lassosmart.com
Errors-To: corraltalkadmin@lassosmart.com
Reply-To: corraltalk@lassosmart.com
Message-Id: <007801c0e60e$f5567af0$0a00a8c0@jj>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Precedence: Bulk
X-Listserver: Macjordomo 1.5  - Macintosh Listserver
Date: Sat, 26 May 2001 19:09:06 +0100
From: "Duncan Cameron" <djcameron@tapaz.com>
To: Multiple recipients of CorralTalk <corraltalk@lassosmart.com>
Subject: Re: my experience with includes and site structure, etc....

Documenting is so, SO important in development and am always suprised to
walk into an application and find nothing especially after freelancers.

It is so annoying, as said before working with a structure that allows
'fellow' developers to take over and know where what is including the
'readme.txt' file and '/* comments' in the templates/includes helps others
and keeps your credibility on a professional platform where it should be.

I know that when working on a salary I always got into 'good habits' as
companies rely on us and so do their shareholders and clients.

deej


----- Original Message -----
From: "Brian K. Middendorf" <bkm@speakeasy.org>
To: "Multiple recipients of CorralTalk" <corraltalk@lassosmart.com>
Sent: Saturday, May 26, 2001 6:37 PM
Subject: Re: my experience with includes and site structure, etc....


> > the key to making this work in the long run is the style guide.  it
covers
> > everything from content tone to visual specs to programming standards.
yeah,
> > just looking at it without a guide would be difficult at first, but if
you
> > have some reference to back it up it's all good.  i figure that if
you're
> > going to be maintaining a mission-critical application/site then you
should
> > spend some effort to get the logic down.  most people doing that are
salary
> > anyways ;)  (me included!)
>
> Makes sense.  My experience maintaining code has been that most people do
> not document.  So a simple fix turns out taking quite a bit of time due to
> having to learn the logic of the system.  I applaud you for documenting
your
> solutions.
>
> > doesn't the encryption thing make debugging a nightmare, especially in a
> > production environment?  nice idea, though...
>
> Not really.  Each page that receives the encryption calls a routine (er,
> includes a file) that decrypts.  At that point the variables can be dumped
> to the screen, written to a database, written to a text file, written into
> comment tags, etc.--whatever technique is used to debug.
>
> I submitted watched variables as a feature request for this very reason.
>
> brian.
>
>
 
